Computers are used in a variety of applications. Networks have interconnected varied computing devices, allowing users to locate and move data across large networks such as the Internet. The data accessed is even more varied and includes multi-media, audio, video, and text in a dizzying range of content formats.
Standard protocols have been developed to access this data across a network. Protocols used to access content include Common Internet File System (CIFS) Internet Small-Computer System Interface (iSCSI), Direct Access File System (DAFS) that sequence through states, and stateless protocols such as the widely-used network file system (NFS). Accessing a file on a server is one example of a content service.
When accessing a data file on a remote server, a client application can generate a request message using one of the file-access protocols and send this message to the server in a lower-level packet such as a Transport-Control-Protocol/Internet Protocol (TCP/IP) packet. The server extracts the message, determines which file-access protocol is being used, and processes the message. A reply message is generated, perhaps containing the requested data file or a pointer to the file. The reply message can then be encapsulated in one or more lower-level packets and transmitted back to the client.
FIG. 1 shows a typical NFS request message. When a file server receives a message embedded in a packet from a client, it processes the message by examining various fields in the message. A NFS_CMD field may have to be read and decoded to determine what kind of request is being made, such as a request to read or write a file. The file server may parse the message to locate a user identifier field.
Other fields in the message can include a file handle or a file name, and other file information such as a generation number and an offset to data within the file. Different commands may require different fields in a message, and the message itself can vary substantially in length.
Several of the message fields can contain variable-length strings. The parent file handle may vary in length. Other fields such as the local file name, offset and generation number may or may not be present in some messages. Some NFS commands may simply request a pointer to the data rather than the data itself, and messages using other protocols may also be received by the file server. Thus a wide variety of request-message formats may have to be processed by a file server.
FIG. 2 shows processing of a message by a file server. A request message such as the request of FIG. 1 is received by a file server and placed in an input buffer. The file server parses the request message to locate the command and user identifier fields. From the command field, the server determines what protocol and command the message contains. The message's syntax can then be checked. The user identifier can be looked up in a user database to determine if the message is from a valid user. Other authentication information may be included in the message such as a password.
Fields in the request message that contain keys to a lookup table are extracted, and these keys are sent to one or more lookup tables to search for an entry containing the extracted key. Keys can include the file handle field, the generation number field, file-name fields, and LINUX identification-node (i-node) fields.
Once a matching entry is found in the look-up table, the results stored in the matching entry are read and the entry verified. A reply message is generated from the results and loaded into an output buffer for transmission to the client. Sometimes further processing is required, and another lookup can be performed. Data pointed to by the results can be read at the offset from the offset field. When the data is located somewhere else, a new request can be generated and sent to another server. The data may also need to be re-formatted.
Since the request message itself can contain many fields, and the fields can contain variable-length strings that must be copied and processed, the file server may require a long, complex routine of instructions to parse and process such messages.
FIG. 3A shows a file server using a general-purpose central processing unit (CPU). CPU 10 receives request messages from a network such as the Internet, and accesses data in files 12, which can be stored on a disk array. CPU 10 is often a computer that uses one or more microprocessors that execute a general-purpose instruction set. CPU 10 is designed for a wide variety of applications, and thus is not optimized for file-access processing.
FIG. 3B highlights a long routine of general-purpose instructions executed to process file-access requests. A simple file-access request such as a NFS lookup command requires execution of a long routine of general-purpose instructions.
An approximate example of a pseudo-C-code routine to perform the NFS lookup instruction is shown in FIG. 3B. Each of the C-code instructions may require several native or assembly-level instructions. For example, the instruction    fhp=&nfh.fth_generic;    requires 2 assembly-code instructions while the function call:    nfsm_srvmtofh(fhp);    requires about 45 assembly-language instructions.The final line in the pseudo C-code, the error function call, could require hundreds of static instructions. Since loops may cause static instructions to be re-executed, the dynamic instruction count can be much higher.
General-purpose instructions to input data, move data, test data are needed to process the NFS lookup command. For example, the message must be parsed to locate fields containing the parent file handle and the file name. The parent file handle and/or the parent file handle combined with the file name are then used during the lookup to locate the proper entry. Look-ups in particular may require execution of many instructions. Loops may need to be repeated, so a routine of 50 instructions may require many hundreds or more instructions to be executed.
While fewer complex instruction set computer (CISC) instructions need to be executed than reduced instruction set computer (RISC) instructions, the number of instructions executed is still quite large, perhaps being hundreds of instructions executed. General-purpose instruction sets include the x86 CISC instruction set by Intel and the PowerPC™ RISC instruction set by Motorola. Very-long instruction word (VLIW) instructions are support parallel processing, but still basically use simple instructions in parallel.
Since many CISC or RISC instructions need to be executed to process even a simple file-access command, a high instruction-fetch bandwidth is needed to fetch the many instructions in the routines. As these instructions are executed, they read and write registers in the processor core. A high bandwidth to these registers is thus also needed. Reading fields in the request message, searching the look-up table, reading data, and outputting the reply message are all I/O-intensive tasks. Most general-purpose processors are inefficient at such I/O tasks.
Parsing the message for variable-length strings such as the parent file handle or the file name may require execution of many instructions. Instructions usually move or process fixed formats of data, such as 8, 16, or 32-bit words. Long, variable-length strings may not fit inside the fixed-width general-purpose registers (GPR's) in the processor core, requiring repeated access of external memory or I/O. Locating a variable-length field in a longer message may require repeated reads and compares.
What is desired is an instruction set that is optimized for processing content-service requests including file-system requests containing variable-length strings. An instruction-set architecture that processes higher-level instructions is desired to reduce instruction-fetch and register-access bandwidth. A higher, functional-level instruction set architecture is desirable.